Nostr 2.0: Layer 2 Off-Chain Data Storage. Syncing Nostr Relays and Paying them to Become Full-Nodes.
Abstract
Nostrは、同期データベースや台帳としてレイヤー1のブロックチェーンを置き換えることはできないだろう。しかし、Nostr 2.0のリレーを同期させるためにレイヤー1のビットコインブロックチェーンを使うことはできる。
Nostr 2.0は、Lightningがビットコインのレイヤー2としてインスタントなオフチェーン決済を提供するのと同様に、ビットコインのレイヤー2として安全なオフチェーンデータストレージを提供できるかもしれない。
これまさしくMonasでやろうとしていることに近いのかも？ Nostrリレーはプロファイルが不完全であることを知らない。リレーには一貫性（CAP定理のC）が欠けている。
一貫性とは、さまざまなコンピュータ間で同期されるデータベースが同一であることを意味する。
ちょうどこんな話してたからなんとなくイメージ付くYudai.icon
だからそこのリレーにないデータはないから色んなリレーと接続しなくちゃいけない
リレーに接続できるようにして外部からそこにあるデータなら取得できるようにできるんやと思う
「特定のユーザーの署名によって署名されたすべての投稿をやみくもに要求する以外に、どのようなデータが欠けているかを発見する手段を持っていない。」
https://scrapbox.io/files/64b612c21fb755001bd22e6b.png
一貫性/同期の問題
2人のユーザーがそれぞれの投稿を別々のNostrリレーにアップロードした場合、Nostrはブロックチェーンとは違うので、2人のユーザーはお互いの投稿を見ることができないかもしれない。ブロックチェーンでは、新しいエントリーがあるたびに、すべてのフルノードがブロックチェーンを同期させる。すべてのフルノードは、ブロックという形で、そのデータをブロックチェーンに一斉に追加する。ビットコインのブロックチェーン上のすべてのフルノードは、まったく同じブロックチェーンを持っています。
=> ユーザーが常に互いの投稿を見ることが出来るようにするには、どのようなデータが書けているのかを特定する方法が必要になる。
https://scrapbox.io/files/64b614368a0e2a001cb89ccc.png
「Nostrリレーと週次オンチェーンMerkleルートと全ツリーハッシュを同期する。」
週に一度程度、自分の投稿を全てMerkle Treeにまとめられる
Merle treeの各Leafにはトランザクションのハッシュが含まれるように、投稿のハッシュが含まれる
通常のBitcoin取引の下にあるOP_RETURNでMerkle Rootをオンチェーンに投稿する
ユーザーはツリー全体のハッシュを取り、Merkle Rootと共にオンチェーンにアップロードする
Tree全体のハッシュを得るには単純にMerkleのルートをテキストファイルの先頭に置く。次に枝をルートの下の行に置く。枝の下に葉を置く。全てをハッシュする。
https://scrapbox.io/files/64b61501e0a95e001bf54005.png
読んでて思うのが全体の状態(動的)はどこかしらで管理する必要があり、ブロックチェーンは一番適しているYudai.icon
それとハッシュってまじで凄い
Merkle RootとWhole tree hashは2つの機能を可能にする
Block全体をダウンロードせずにトランザクションをダウンロードできる
全ツリーハッシュは保存しているプロファイルが不完全であることをユーザーとリレーに知らせる。
(最新hash ) －(現在持っているhash) = 同じかどうかで分かるYudai.icon
同じ = 完全
個人スコアのRoot hashをオンチェーン上に書き込む
SBTにより瞬間的な状態(現在持っているhash)を保存していた。
膨らませると検証者は最新かどうかを検証することができるってこと
最新(Time stamp的に)かどうかを検証する
信頼最小化の3つのレイヤー
レイヤー1では検閲が非常に難しい、不変かつ高価なデーったストレージ
検閲が中程度に困難なレイヤー2上の不変で安価なデータストレージ
検閲が容易なローカルデバイス間んで同期されたローカルデータストレージ
Nakamoto Consensus blockchainとNostrのトレードオフ
特定のアドレスのデータを保存するNostrリレーが多ければ多いほど、そのデータを検閲するのは難しくなる。つまり、多くのNostrリレーによってホストされている人気データは、めったにダウンロードされない不人気データよりも検閲が難しい可能性があるということだ。
一方、Nakamoto Consensusブロックチェーンは、データの年齢による検閲を防ぐことができる。データがブロックチェーンに存在する時間が長ければ長いほど、51%攻撃で削除するのが難しくなる。
..信頼できるサードパーティを必要としない...我々はまた、クライアントのデータがサーバによって正しく保存されていることの証明を提供するためにクライアントがサーバに支払う、Proof of RetrievabilityのケースのためのZKCSPプロトコルを実装している"
Peer Discovery Landerboard as DHT 分散型ハッシュテーブル内でどの公開鍵のデータを保存しているかをリストアップする事でホワイトリストを共有できる。
こうすることである公開鍵のデータのブランチが見つからないリレーはDHTをスキャンし、見つからないブランチを保存していると主張する他のIPアドレスに直接接続できる
これ、めっちゃIPFSでCID(Block)を探す構図に似ているYudai.icon なんかどこも重要な機能は同じなんだ
ユーザーがLightningのトランザクションをすべて束ね、ブロックチェーンに小さな証明を置くのと同じように、私たちはNostrのデータをすべて束ね、ブロックチェーンに小さな証明を置くつもりです。Lightningがレイヤー2で行っているような即時決済を提供する代わりに、怪しいサイドチェーンのような恐ろしいセキュリティリスクなしに、レイヤー2でデータストレージを提供することができるかもしれない。